Historic Portfolio Management System Architecture
Referring to FIG. 1, in the world of managed accounts, an individual investor 10 desires to open a single brokerage account (BA) with multiple investment styles with a brokerage firm 14 through the investor's financial advisor or broker 12, who will sometimes be referred to simply as the advisor or financial advisor and may be a member of the brokerage firm 14, as indicated by the dotted lines. The multiple investment styles are implemented for the investor through the opening of multiple separately managed trading accounts. Due to the limitations of the architecture of FIG. 1, distinct accounts must be opened by the by broker, and the investor is typically not shielded from this fact (the BA primarily reflects the relationship between broker and investor).
Let us say, for example, that the account is initially opened in the amount of $500,000. The brokerage firm 14 will commonly split the $500,000 amount within the BA amongst multiple trading accounts. For this example, we will assume that the $500,000 amount is split between four (4) separate trading accounts at the brokerage firm. The trading accounts are represented in FIG. 1 as TA1, TA2, TA3 and TA4. The trading accounts are associated with the single brokerage firm 14. The trading account data for TA1, TA2, TA3 and TA4 is entered into a database 26A of the automated brokerage firm portfolio management system (BFPMS) 26 utilized by the brokerage firm 14.
After the trading accounts TA1, TA2, TA3 and TA4 have been opened by the brokerage firm 14, the brokerage firm must also open four (4) separate custodial trading accounts, represented in FIG. 1 as CTA1, CTA2, CTA3 and CTA4, at the custodian firm 16. The four (4) custodian trading accounts are entered into a database 28A of the custodian account management system (CAMS) 28 conventionally utilized by the custodian firm 16, and typically associated with the tax identifier, i.e. tax ID, of the investor 10. The official and formal records for the trading accounts TA1, TA2, TA3 and TA4, and hence the single BA, will be the records for the custodial trading accounts CTA1, CTA2, CTA3 and CTA4, as maintained by the custodian firm 16.
The advisor 12, will most typically recommend to the investor 10 that each of the individual trading accounts be assigned to a different money manager to increase diversity and reduce risk for investor 10. In this example, we will assume that the trading accounts TA1, TA2, TA3 and TA4, will be respectively assigned to money manager A 18, money manager B 20, money manager C 22 and money manager D 24. Each of these money managers will preferably have a different investment style, which typically reflects a particular investment philosophy. For example, in this case, the respective money manager styles might be large cap growth, large cap value, small cap and fixed income. Thus, each of the four (4) trading accounts TA1, TA2, TA3 and TA4, will be assigned to a different one of the four money managers 18-24.
Each money manager will open a separately managed trading account, which will sometimes be referred to as an MTA. The managed trading accounts are represented in FIG. 1 as MTA1, MTA2, MTA3 and MTA4. The trading account records for each of MTA1, MTA2, MTA3 and MTA4 are entered into a database 30A of an automated money manager portfolio management system (MMPMS) 30 conventionally utilized by each of the money managers 18-24.
It should be understood that, although the MMPMS shown for each of the money manager's 18-24 is referred to using the same reference numeral, each MMPMS could be different from the other MMPMSs. Because each of the money managers 18-24 manages a separately managed trading account, i.e. manages a different one of MTA1, MTA2, MTA3 and MTA4, each of the managed trading accounts are managed separately according to the applicable money manager's individual investment style. Thus, in actuality, although it appears to the investor 10 that he or she has only a single managed BA with the brokerage firm 14, in reality he or she has had multiple separate trading accounts combined for reporting. In this case the four (4) trading accounts TA1, TA2, TA3 and TA4, amongst which the invested amount, i.e. in this example $500,000, is divided and separately invested and managed using different investment styles. Since the managed trading accounts are separate accounts, each of the money managers 18-24 could independently perform certain functions on its MTA. For example, each of the money managers 18-24 could independently rebalance its MTA for investor 10 to its style model, and perform different “what if” scenarios on its MTA for investor 10 to determine how that account will be affected by a purchase or sale of a certain security, e.g. publicly traded shares of a particular company. Each of the money managers 18-24 could also independently place individual restrictions on its MTA for the investor 10. In this regard, if the investor 10 is employed by a certain company and purchases that company's shares through an employee stock purchase program, the investor 10 may not want the money manager to buy any more securities in that company. In such a case, the applicable money manager can restrict the purchase of the company's shares for the MTA of the investor 10 which it manages. To avoid such purchases, the money manager will typically enter the restriction in the applicable MMPMS for the investor's MTA. The MMPMS will then automatically prevent or issue a warning, if there is an attempt to purchase the company's stock with funds from the investor's MTA being managed by that money manager.
As the money managers 18-24 makes decisions on the managed trading accounts MTA1, MTA2, MTA3 or MTA4, the associated trade orders, e.g. orders to buy securities or sell securities in a particular company, are initiated by the money managers 18-24 and forwarded to the brokerage firm 14. Based on the issued orders, the brokerage firm 14 executes the trades in fulfillment of the orders. In this regard, the brokerage firm 14 will, through its trading desk, execute the buys and the sells to actually perform the ordered trades.
After fulfillment of one or more orders, the brokerage firm 14 forwards a file representing the executed buys and sells to the custodian 16. Based on the information represented in the forwarded file, the custodian 16 records the trades in the books and records for the applicable custodial trading account, i.e. CTA1, CTA2, CTA3 or CTA4. The brokerage firm 14 will also forward the prices of the executed buys and sells associated with an order(s) of a particular one of the money managers 18-24 to that money manager. For example, if the brokerage firm 14 purchased 100 shares of IBM at an $80/share price, the $80 purchase price is forwarded to the custodian 16 and the applicable money manager 18-24 for recording in the applicable CTA maintained by the CPMS and the applicable MTA maintained by the applicable MMPMS, respectively. Once the books and records for the custodial trading accounts CTA1-CTA4 have been modified by the custodian 16 to reflect the actually executed orders, in accordance with the files forwarded from the brokerage firm 14, the brokerage firm 14 and the money managers 18-24 will reconcile TA1-TA4 and MTA1-MTA4, with the modified books and records of the custodian 16 for CTA1-CTA4. Thus, information, in the form of a file representing the information associated with the CTAs, flows back from the custodian 16 to the brokerage firm 14 and from the brokerage firm 14 to the money managers 18-24. Accordingly, both the TAs maintained by the brokerage firm 14 and the MTAs maintained by the money managers 18-24 on their respective portfolio management systems, shadow the CTAs maintained by the custodian 16 on the CPMS. It will be understood that the prices are returned almost immediately, and almost always within the same trading day, while the custodian information is not returned until the next business day.
As described above, each of the money managers 18-24 will have a single MTA for the investor 10, while the brokerage firm 14 will have multiple separate TAs for investor 10. The brokerage firm 14 may report on the TAs to the investor 10 by presenting four (4) separate trading account statements, i.e. one for each of TA1-TA4. The brokerage firm 14 may also, or alternatively, manually roll the separate statements into one single brokerage account statement that is reported to the investor 10. Each of the money managers 18-24 may also independently present a managed trading account statement for the MTA which it manages, to the investor 10.
Current Portfolio Management System Architecture with Single Managed Client Account and Overlay Manager
As described above with reference to FIG. 1, using the historical brokerage firm portfolio management system architecture, brokerage firms had to open multiple trading and custodial trading accounts. Typically, a different trading account was opened for each investment style or assigned money manager. Since, using this architecture, statements could only be generated by the MMPMS for each individual managed trading account, the brokerage firm was required to either report on each of the trading accounts separately or manually combine the multiple different statements associated with the managed trading accounts to present a single brokerage account statement to the investor. The need to generate multiple trading account statements, i.e. one for each managed trading account, and manually combine these statements into a single brokerage account statement, made reporting to the investor difficult and more expensive for the brokerage firm. For the investor, the need to review multiple trading account statements for a single brokerage account made the review complex, and the statements difficult to understand and use.
More recently, system architectures have been introduced to simplify the reporting and provide greater automation. One such recently introduced architecture is shown in FIG. 1A. In the FIG. 1A architecture, an overlay manager, represented by a master overlay manager (MOM) 50, allows the brokerage firm 14 to maintain a single client account (CA) in the database 32A of the brokerage firm portfolio management system (BFPMS) 32. It should be understood, that the MOM 50 could be a separate system, which might be operated by a global money manager, or could be functionally included as part of one of the money manager portfolio management systems (MMPMS) 36, e.g. part of the MMPMS 36 for money manager 20 as indicated by one set of dotted lines, or could be functionally included as part of the BFPMS 32 as indicated by the other set of dotted lines.
Notwithstanding where the master overlay manager functionality resides, because only a single CA need be maintained, the brokerage firm 14 also need only open, and the custodian 16 need only maintain, a single custodial client account (CCA) in the database 34A in the custodian portfolio management (CPMS) 34, to record transactions associated with the CA performed in accordance with multiple different investment styles. The different investment styles are reflected in the style models, i.e. SM1-SM4, of the money managers 18-24 which are stored in memory 36C of the MMPMSs 36, which are incorporated in a single overlay model (OM). Now, rather than generating multiple trading account statements, i.e. one for each style, the MOM 50 or the brokerage firm 14 are capable of automatically generating a single managed client account (MCA) statement for reporting to the investor 10. Thus, using MOM 50 of FIG. 1A, reporting has been simplified for the brokerage firm 14. For the investor 10, the single MCA statement is easier to understand and use. Additionally, the investor 10 need no longer be burdened with multiple different managed trading account (MTA) statements for the same account.
Alternative Current Portfolio Management System Architecture with Single Managed Client Account, Multiple Trading Accounts and Overlay Manager
FIG. 1B depicts a recently introduced variation of the portfolio management system architecture depicted in FIG. 1. This new architecture includes a limited-functionality overlay manager represented by an alternate master overlay manager (AMOM) 50′ which also allows consolidation of the multiple trading account (MTA) reports, but is otherwise identical to the architecture of FIG. 1. Here again, the AMOM 50′ could be a separate system, which might be operated by a global money manager, or could be functionally included as part of one of the alternative money manager portfolio management system AMMPMSs 36′, e.g. part of the AMMPMS 36′ for money manager 20 as indicated by one set of dotted lines, or could be functionally included as part of the BFPMS 36′ as indicated by the other set of dotted lines.
As will be discussed further below, the individual money managers 18-24 initiate trade orders for and otherwise manage the MTAs. These transactions are compiled by the AMOM 50′ into a single alternative managed client account (MCA′). Although multiple trading account statements, i.e. one for each style, are generated by each of the AMMPMSs 36′, the AMOM 50′ in the FIG. 1B architecture, is capable of automatically generating a single MCA′ statement for reporting to the investor 10 on the BA basis, by compiling the multiple the MTA statements generated by the AMMPMSs 36′. Thus, using AMOM 50′ of FIG. 1B, reporting has been simplified for the brokerage firm 14. For the investor 10, the single MCA′ statement is easier to understand and use. Additionally, the investor 10 need no longer be burdened with multiple different statements for what he or she considers the same account. Unlike the FIG. 1A architecture, the portfolio management system architecture of FIG. 1B, like the more historic architecture of FIG. 1, beneficially also allows the money managers 18-24 to manage each style in a separate managed trading account.
To summarize, currently available portfolio management system architectures, such as those depicted in FIGS. 1A and 1B, provide the brokerage firm with the ability to establish and maintain only one client account in the case of the FIG. 1A architecture, and to generate and forward one consolidated account statement to the investor in the FIGS. 1A and 1B architectures, notwithstanding the number of trading styles used for the account. This has simplified the entire investment portfolio management process for both the brokerage firm and the investor.
Brokerage Firm Portfolio Management System (BFPMS)
FIG. 2 is an exemplary depiction of the conventional brokerage firm portfolio management system (BFPMS) 32 shown in FIG. 1A, and further details the functionality of the BFPMS 32. The functionality of the BFPMS 26′ in FIG. 1B is identical to that of the BFPMS 26 in FIG. 1, except for the interface to the AMOM 50′, As shown, the BFPMS 32 includes the database 32A having data representing a single client account (CA) for the investor 10. The BFPMS also includes a processor 32B that includes the logic, e.g. programmed instructions, necessary to perform various functions. As shown, these functions include a function to direct the opening of a client account 32B1 which performs the necessary operations to open the single CA for the investor 10, an open custodial account function 32B2 which performs the necessary operations to direct the custodian account management system (CAMS) 28 to open the custodian client account (CCA) for the investor 10, and a direct order execution function 32B3 which performs the necessary operations to direct the execution of orders placed by either the overlay manager, in the case of the FIG. 1A architecture, or the money managers 18-20, in the case of the FIG. 1B architecture.
Money Manager Portfolio Management System (MMPMS or AMMPMS)
FIG. 3 is an exemplary depiction of the conventional money manager portfolio management system (MMPMS) 36 and or alternate conventional money manager portfolio management system (AMMPMS) 36′ shown in FIGS. 1A and 1B, and further details the functionality of the MMPMS and AMMPMS.
As shown, the MMPMS 36 of FIG. 1A and the AMMPMS 36′ of FIG. 1B include the database 36A having data representing a managed trading account (MTA) for the investor 10. As discussed above, because all trade ordering and account management functions are performed by the MOM 50 at the MCA level in the FIG. 1A architecture, there are no MTAs to be managed by the individual money managers 18-24 using the FIG. 1A architecture and hence the MMPMS 36 of FIG. 1A has no need for a database 36A to maintain an MTA.
The MMPMS 36 of FIG. 1 and the AMMPMS 36′ of FIG. 1B also include a processor 36B which includes the logic, e.g. programmed instructions, necessary to perform various functions. As shown, these functions include, but are not limited to, a rebalancing accounts function 36B1, a tax efficient trading function 36B2, a wash sales function 36B3, a drift function 30B4, a generate trade orders function 36B5 and a generate MTA function 36B6 which performs the necessary operations to generate a statement for its associate MTA. Here again, and as discussed above, because all trade ordering and account management functions are performed by the MOM 50 at the MCA level in the FIG. 1A architecture, there are no MTAs to be managed by the individual money managers 18-24 and hence no need for the AMMPMS 36′ of FIG. 1B to perform the functions 36B1-36B6 or to include the processor 36B to perform such functions.
Both the MMPMS 36 and AMMPMS 36′ include a memory 36C that stores a style model (SM) for the investment style utilized by the applicable money manager. As discussed above, in the case of the MMPMS 36 the stored SM is incorporated in the overlay model (OM) utilized by the MOM 50 to generate trade orders and manage activity on the single managed client account (MCA). Hence, in the FIG. 1A architecture, the applicable SM is stored on the MMPMS 36 only for the purpose of recording modifications made to the stored SM made by the applicable money manager. These modifications are then forwarded to the MOM 50 for incorporation in the overlay model (OM) for the investor 10. On the other hand, in the case of the AMMPMS 36′, the processor 36B will utilize the stored SM in performing functions 36B1-36B4 and 36B6, as applicable, for the applicable MTA of the investor 10 stored in the database 36A.
With regard to the rebalancing accounts function 36B1, money managers 18-24 have historically rebalanced one managed trading account or style at a time. That is each managed trading account, i.e. each of MTA1-MTA4, is separately rebalanced to bring that account back in line with the particular model for that style. As described above, each money manager has a particular SM stored in the memory 36C of the AMMPMS 36′ associated with that money manager. For instance, a large cap growth style would have a static model requiring certain number of securities and cash to make-up 100% of the MTA. Each MTA must be rebalanced by the applicable AMMPMS 36′ to the individual style, i.e. the individual SM, of the applicable money manager. To do this, the AMMPMS processor 36B, executes the rebalance account function 36B1 to determine the deviation of the MTA in the database 36A from the SM stored in the memory 36C. It then generates trade orders by executing the generate trade order function 36B5, to reduce or eliminate the determined deviation and thereby place the MTA in line with the SM.
With regard to the tax efficient trading function 36B2, the investor 10 may require that certain lots of or positions in securities held in the MCA be sold at a loss to off-set gains made earlier in a tax year, and thereby reduce the tax burden on the investor 10. This is commonly referred to as tax harvesting. To do this, the applicable AMMPMS processor 36B, executes the tax efficient trading function 36B2 to identify the lots of or positions in securities that should preferably be sold from the applicable MTA to offset the gains due to prior sales of securities in that MTA. It then generates trade orders, by again executing the 36B5 function, to sell the identified securities, and thereby reduce or eliminate the prior gain for the tax year and the associated investor tax burden. With regard to the wash sale function 36B3, a wash sale violation arises when a security in one MTA was previously sold at a loss for the investor 10 and the same security is repurchased for any of MTA1-MTA4 for investor 10 within thirty-one days, or some other predetermined period, of the sale. In order to tract potential wash sales, the money managers 18-24 must ensure that a security on which the money manager is issuing a purchase order was not sold at a loss for the investor 10 by it or any other money manager during the relevant period, e.g. during the prior thirty days. However, the applicable AMMPMS processor 36B, executes the wash sales function 36B3 to identify only whether a security that the applicable money manager intends to purchase for the applicable MTA was previously sold from that MTA at a loss during the relevant period. After determining that no such sale previously occurred, the AMMPMS processor 36B executes the generate trade order function 36B5 to generate a trade order to purchase the security, thus avoiding a wash sale violation with respect to trading activity relating to the applicable MTA, but not with respect to other MTAs of the investor 10.
There are other conditions that money managers 18-24 have to deal with in the FIG. 1B architecture. One is, monitoring and managing drift within a single MTA, which is performed by the drift function 36B4. Each of the money managers 18-24, are concerned with the drift of an individual security or other holding in the MTA which it manages for the investor 10, away from the conditions for that security or other holding set forth in the SM stored in the memory 36C for that MTA. Historically, the money managers 18-24 tracked such drift manually. To do this, each money manager would need to go through its MTA for the investor 10 looking for securities or holdings that have become over or under rated, and then adjust the securities or holdings accordingly.
In the architecture of FIG. 1B, the AMMPMS processor 36B performs the drift function 36B4 by monitoring and managing drift at the security level within the applicable MTA in an automated manner. To do this, the applicable AMMPMS processor 36B, executes the drift function 36B4 to identify whether a security or other holding in the applicable one of MTA1-MTA4 in the database 36A has drifted outside of a range, which may be established by the processor 36B or stored in the memory 36C, from a position for that security or holding established in the SM stored in the memory 36C. The processor 36B then executes the generate trade order function 36B5 to initiate trade orders to reduce or eliminate the drift and thereby place the applicable MTA in line with the applicable SM. Since drift is reduced or eliminated one style, i.e. one MTA, at a time and the drift reduction or elimination in each style is typically performed by a different AMMPMS 36′, the drift in a single client account with funds invested across multiple MTAs is reduced by the MMPMS 36′ only on a style-by-style basis. Style-by-style drift monitoring may result in an inefficient number of corrective trades for multiple MTAs.
Master Overlay Manager (MOM or AMOM)
As discussed above and shown in FIGS. 1A and 1B, current portfolio management system architectures include one of two types of master overlay managers, i.e. the MOM 50 of the FIG. 1A architecture or the AMOM 50′ of the FIG. 1B architecture. The MOM 50 or AMOM 50′ may be in the form of a separate system, or be incorporated as part of the BFPMS 32, or MMPMS 36 or AMMPMS 36′.
FIG. 4 is an exemplary depiction of the conventional master overlay manager (MOM) 50 shown in FIG. 1A, and the conventional alternate master overlay manager (AMOM) 50′ shown in FIG. 1B, and further details the functionality of the MOM 50 and AMOM 50′.
As shown, the MOM 50 and AMOM 50′ include a processor 50A that includes the logic, e.g. programmed instructions, necessary to perform one or more functions. These functions differ depending on whether the processor 50A is included in the MOM 50 or the AMOM 50′.
In the case of the MOM 50 of the FIG. 1A architecture, these functions include a rebalancing managed client accounts function 50A1, a managed client account tax efficient trading function 50A2, a managed client account wash sales function 50A3, a managed client account cross style drift function 50A4, a generate trade order function 50A5 and a generate MCA statement function 50A6. Because trade ordering and account management functions are performed by the AMMPMSs 36′ at the MTA level in the FIG. 1B architecture, there is no truly managed client account (MCA) to be managed by the AMOM 50′ and hence no need for AMOM 50′ to perform the functions 50A1-50A6.
However, in order for the AMOM 50′ to compile the MTA′s maintained by the AMMPMS 36′ into what can be viewed by the investor as a single managed client account (MCA′), the AMOM 50′ includes a generate MCA′ function which is executed by processor 50A to combine the records for MTA1-MTA4, into a single MCA′ record and to modify the MCA based on transaction information received for each of MTA1-MTA4. In the case of the AMOM 50′ of the FIG. 1B architecture, the functions performed by the processor 50A also include a generate MCA′ statement function 50A8, which either combines the individual MTA statements generated by the AMMPMSs into a single corresponding MCA′ statement or generates an MCA′ statement from the MCA′ record. Alternatively, the generate MCA′ statement function 50A8 could generate the consolidated MCA′ statement dynamically from individual MTA information, and not require the creation and maintenance of the MCA′ at all. In this discussion, the existence of the MCA′ is assumed.
The MOM 50 also includes a memory 50B which stores an overlay model (OM) for the MCA. The OM combines the style models, e.g. SM1-SM4, for each of the investment styles, e.g. style1-style4, into the OM for the MCA being utilized for the investor 10, reflecting a desired allocation distribution across the styles as well as potentially other overlay parameters. As discussed above, because, in the FIG. 1B architecture, all trade ordering and account management functions are performed by the AMMPMS 36′ at the MTA level and the results are simply compiled by the AMOM 50′ at the MCA′ level in the FIG. 1B architecture, there is no OM required in the FIG. 1B architecture, and hence AMOM 50′ has no need for a memory 50B for storing an OM. Both the MOM 50 and AMOM 50′ include a database 50C which stores a master client account (MCA) in the case of MOM 50 and an alternate master client account (MCA′) in the case of AMOM 50′. In the case of the FIG. 1A architecture, the MCA is shadowed, as will be further discussed below, by the BFPMS 32 of FIG. 2 as the CA stored in the BFPMS database 32A. If the MOM 50 is incorporated within the BFPMS 32, the CA stored in the BFPMS database 32A will be utilized in lieu of the MCA, eliminating the need for the database 50C.
In the case of the FIG. 1A architecture, all trade orders are initialed and all account management functions are performed by the MOM 50 at the MCA level. Accordingly, the MCA stored in database 50C of MOM 50 is independently generated and maintained by the MOM 50. The MOM 50 has no need to coordinate with or receive information, other than the SMS and modifications thereto, from the individual money managers 18-24 to transact and manage the MCA.
In the case of the FIG. 1B architecture, the MCA′ is a compilation of the individual MTAs stored in the AMMPMSs 36′. Since all trade orders initiated and most account management functions are performed by the individual AMMPMSs 36′ at the MTA level, the MCA′ stored in database 50C of AMOM 50′ merely shadows to the MTAs independently generated and maintained by the respective AMMPMSs 36′.
With regard to the rebalancing client account function 50A1, the brokerage firm 14 has historically, at best, performed a manual rebalancing of individual securities across all for the MTAs, i.e. MTA1-MTA4. That is, all the securities in the managed trading accounts MTA1-MTA4 for the investor 10 were at best manually rebalanced to bring the securities back in line with the desired security allocation for that investor.
The MOM 50 can perform an automated rebalancing of the single MCA maintained in the database 50C, based on the multi-style OM for the MCA of the investor 10 stored in the memory 50B of the MOM. For example, the multi-style OM for a particular MCA might require certain number of securities, within the MCA, to make-up 100% of the capital. The MCA must be rebalanced by the MOM 50 to the OM. To do this, the processor 50A, executes the rebalance account function 50A1 to determine the deviation of the MCA securities in the database 50C from the security allocation of OM stored in the memory 50B. It then generates trade orders by executing the generate trade order function 50A5, to reduce or eliminate the determined deviation and thereby place the MCA, and hence the CA stored at the brokerage firm 14, in line with the OM for the investor 10.
With regard to the MCA tax efficient trading function 50A2, as discussed above, the investor 10 may require that certain lots of or positions in securities held in the MCA be sold at a loss, i.e. the loss harvested, to off-set gains made earlier in a tax year, and thereby reduce the tax burden on the investor 10. To do this, the processor 50A of the MOM 50, executes the MCA tax efficient trading function 50A2 to identify the lots of or positions in securities that should preferably be sold from the MCA of the investor 10 to offset the gains due to prior sales of securities in the MCA of investor 10. It then executes the generate trade order function 50A5 to initiate trade orders to sell the identified securities, and thereby reduce or eliminate the prior gain for the tax year and the associated investor tax burden.
With regard to the MCA wash sale function 50A3, as discussed above, a wash sale violation arises when a security in the MCA of investor 10 was previously sold at a loss for an investor and the same security is repurchased for the MCA within thirty-one days, or some other predetermined period, of the earlier sale. In order to tract potential wash sales, the MOM 50 insures that a security for which a purchase order is issued was not sold at a loss for the investor 10 during the relevant period, e.g. the prior thirty-one days. To do this, the processor 50A of the MOM 50, executes the CA wash sales function 50A3 to identify whether a security proposed to be purchased for the MCA of the investor 10 was previously sold from that MCA at a loss during the relevant period. Only after determining that no such sale previously occurred, will the processor 50A of the MOM 50 execute function 50A5 to generate a trade order to purchase the security, thus avoiding a wash sale violation with respect to trading activity relating to the MCA. The MOM 50 will also monitor and manage drift between the multiple styles associated with the MCA of the investor 10, using the MCA cross style drift function 50A4. In this regard, the MOM 50 is concerned with the drift between different styles used to invest the capital in that MCA in database 50C of MOM 50, away from the allocation across the multiple styles set forth in the OM stored in the memory 50B of the MOM 50. Historically, the brokerage firm 14, at best, tracked such across style drift manually. To do this, the brokerage firm would need to go through the performance and market value of the individual MTAs, looking for accounts that have become over- or under-weighted, and then adjust the MTAs accordingly. A drift between the individual styles at the MCA level could, for example, occur because some of the multiple styles have performed better than others, resulting in an increase in the individual market value of the securities invested in some of the styles and a decrease in the value of the securities invested in other styles for MCA of the investor 10. Based on this manual monitoring, the brokerage firm would manually direct a redistribution of the cash among the multiple MTAs for the investor 10 to counter any determined drift between the various styles, i.e. between the multiple MTAs, and thereby realign the MTAs, which had become overrated or underrated, with a desired style allocation. Thus, historically the money managers 18-24 and brokerage firm 14 were not proactively alerted when a MTA violated certain style drift tolerances based on a desired style distribution.
The processor 50A of the MOM 50 performs the MCA across style drift function 50A4 and proactively monitors and manages across style drift within the MCA for the investor 10 in an automated manner. To do this, the processor 50A of MOM 50 executes the across style drift function 50A4 to identify whether a style of securities in the MCA of investor 10, has drifted outside of a range, which may be computed by the processor 50A or stored in the memory 50C, from the style allocation established in the OM stored in the memory 50B. The processor 50A then generates trade orders, by executing the generate trade order function 50A5, to reduce or eliminate the drift and thereby place the MCA for the investor 10, and hence the CA maintained by the brokerage firm 14, in line with the OM. Since drift is reduced or eliminated for the entire MCA, not just one style, the drift in a single MCA with funds invested among multiple styles is reduced by the MOM 50 on an entire account, not a style-by-style, basis.
The processor 50A of the MOM 50 also executes the generate MCA statement function 50A6 to create statements for reporting on the MCA of investor 10. By executing function 50A6, the processor 50A of MOM 50 is capable of generating statements on both an individual style basis and an entire MCA basis. As will be described further below, these statements may include performance information for the MCA on a style-by-style or entire account basis.
Referring now to the functions performed by the AMOM 50′ in the FIG. 1B architecture, the combine MTAs function 50A5 is executed by the processor 50A of the AMOM 50′ to combine and organize the records stored for each of the individual MTAs, i.e. MTA1-MTA4 at the respective AMMPMSs 36′ into the MCA′ stored in the database 50A of the AMOM 50′. The processor 50A of the AMOM 50′ will also modify the MCA′ in correspondence with modifications to the MTAs over time based on information received from the AMMPMSs 36′.
The processor 50A of the AMOM 50′ also executes the generate MCA′ statement function 50A8 to create statements reporting on the MCA′ of investor 10. By executing function 50A6, the processor 50A8 is capable of generating statements on an entire MCA′ basis only. These statements may include performance information for the MCA′ on an entire account basis only. Statements reporting on the individual MTAs, as discussed above, are created by the respective AMMPMS 36′ in the architecture of FIG. 1B.
In summary, the MOM 50 can rebalance many styles at the same time, by rebalancing a single MCA, and hence rebalance the shadow CA at the brokerage firm 14. The MOM 50 can also transact in many styles in one MCA, making it much more efficient to harvest tax loses in an automated manner, by considering all of the lots of or positions in securities in the MCA to obtain the most efficient tax loss, and thereby harvesting across multiple different styles. Additionally, the MOM 50 is able to avoid wash sale violations which could occur across styles in an automated manner by tracking potential wash sales within the single MCA so as to insure that a security in any style which the overlay manager intends to purchase for the MCA of the investor 10 was not sold at a loss for the investor 10 during the relevant period from the MCA. Furthermore, the MOM 50 will proactively issue an alert when the MCA has violated certain style drift tolerances based on a desired style allocation set forth in the OM. Both the MOM 50, and AMOM 50′ are capable of maintaining and reporting on a single master client account, i.e. MCA or MCA′ for the investor 10, notwithstanding the use of multiple investment styles.
While the MOM 50 and AMOM 50′ have significantly enhanced management capabilities for multiple style portfolios by implementing the above described functionality, the MOM 50 restricts each of money managers 18-24 from managing trading within its particular style. The AMOM 50′, while allowing each of the money managers 18-24 to manage trading within its MTA, does not allow the overlay manager to manage a single multistyle account. Hence, a new architecture is required which will allow each of the money managers 18-24 greater flexibility then the current portfolio management system architecture of FIG. 1A to trade and work within their portion of the single client account, while providing the overlay manager with greater flexibility than the architecture of FIG. 1B to manage an investment portfolio across styles.
For example, with regard to the cash management, cash or credit deposits of the investor 10 must be split up amongst the multiple styles to be utilized. Historically, the distribution of these deposits has been performed manually by the brokerage firm 14. That is, with reference to FIG. 1, as cash or credit deposits were made by the investor 10, the brokerage firm 14 would split the deposit up among the different styles, i.e. the different MTAs, and hence, the different money managers 18-24.
The FIGS. 1A and 1B architectures do not provide any automation when it comes to the allocation of assets. The process is still manually performed by the brokerage firm 14.
For instance, if an initial $1,000,000 account were allocated 40% or $400,000 to growth, and it was subsequently desired to redistribute a greater share of the account to growth, historically, the brokerage firm would manually initiate a draw from other style money managers and deposit the drawn amount to the growth money manager. This, for example, might increase the allocation to the growth money manager from 40% of the market value for the entire account of the investor 10, to the desired 50% or 60%. Neither the MOM 50 or AMOM 50′ has provided any automation to this process.
Hence, in the current portfolio management system architectures shown in FIGS. 1A and 1B the investor 10 will still open a single brokerage account with the brokerage firm 14, via his/her financial adviser 12, by making a deposit, e.g. $500,000, with the brokerage firm 14. However, the brokerage firm 14, rather than opening and maintaining multiple trading accounts for the investor 10, i.e. one trading account per style, as shown in FIG. 1, now opens and maintains a single client account for the investor at the brokerage firm 14 as shown in FIG. 1A. Additionally, rather than opening multiple custodial trading accounts for the investor 10 at the custodian 16, i.e. one custodian trading account per style, as shown in FIG. 1, the brokerage firm 14 now opens a single custodial client account for the investor 10 at the custodian 16, as shown in FIG. 1A.
In the FIG. 1A architecture, use of the overlay model (OM) allows multiple styles to be applied within the single managed client account. The master overlay manager 50 controls the functioning of the single managed client account, including the trading, the reporting, and all other functioning required to manage the account. On the other hand, in the FIG. 1B architecture, there is no overlay model. Rather, separate managed trading accounts managed by different money managers continue to be utilized. This allows multiple styles to be applied to different portions of the single managed client account. The individual managers retain control over the management of respective portions of the single managed client account, including the trading, some of the reporting, and other functioning required to manage the account. The overlay manager compiles information from the separate money managers to provide overall account reporting.
The MOM 50 or AMOM 50′ might reside within a special overlay management department of the brokerage firm 14. This department might have the responsibility to control the client account activity utilizing the functionality available in the MOM 50, or the reporting to the investor utilizing the functionality available in the AMOM 50′. The department could, if desired, retain the multiple money managers 18-24, from within or from outside the brokerage firm 14. In the case of the MOM 50, the money managers 18-24 only provide individual style models for incorporation into the master overlay model (OM). In the case of AMOM 50′ the money managers are retained to trade and work within their respective portions of the single client account.
On the other hand, the MOM 50 or AMOM 50′ could reside with a global money manager, which could be an entirely separate entity from the brokerage firm 14 and money managers 18-24, or could reside with one of the individual style money managers, such as money manager 20 in FIGS. 1A and 1B. In either case, the single managed client account is managed utilizing the MOM 50 or AMOM 50′ in much the same way as a special department within the brokerage firm 14.
The global money manager could also retain other money managers, either from within or outside the firm, to either provide style models or to trade and work within a portion of the single managed client account. However, unlike in the case of the MOM 50 or AMOM 50′ residing at the brokerage firm 14, the money manager must forward trade orders to the brokerage firm 14. The executed trades would then flow back and forth between the money manager and the brokerage firm.
It should be understood that, if the MOM 50 resides outside the brokerage firm 14, the BFPMS 32 and MOM 50 would both maintain separate identical client accounts, i.e. the CA and MCA. The BFPMS will often be utilized to monitor the single client account.
Risk Category Determination
In all the architectures of FIGS. 1-1B, as shown in FIG. 5, the advisor 12, working with the investor 10, performs a risk assessment in step 100 to determine the appropriate risk category for the investor. The advisor 12 performs the risk assessment on the investor 10 based on the investor's profile, age, demographics, income, retirement age and other factors well understood by those skilled in the art. Based on the results of the risk assessment, the advisor 12, in step 102, selects the proper risk category. In the exemplary flow depicted in FIG. 5, the advisor selects between risk categories 1-4 that are identified with the reference numerals 104A-104D. There could of course be more or less risk categories considered. For this example, it is assumed that the advisor 12 selects category 1.
In the system architecture of FIG. 1A, the MOM 50 associates each risk category with specific investment products offered by the brokerage firm 14. As shown, category 1 has products 1 and 2, identified with reference numerals 106A and 106B. The other risk categories have associated products 2-8, identified by reference numerals 106C-106H. Here again, it will be recognized that there could be more or less products associated with each category. In step 108, the advisor 12 selects the product from those offered for the selected risk category. In this example, the advisor 12 selects product 1.
Each of the offered products 106A-106H has a predetermined asset allocation. For instance, if the selected risk category is a low risk category, i.e. a category appropriate for an investor with a low risk tolerance, the category might have an asset allocation of 50% for fixed income investment and 50% value investment. On the other hand if a risk category is a higher risk category, i.e. a category appropriate for an investor with a higher risk tolerance, the category might have an asset allocation of 70% or 80% growth investment and 20% or 30% fixed income investment. These asset allocations are predetermined based on the risk for the risk category.
Also each of the products 106A-106H has a group of predefined styles, and money managers for managing the respective individual styles. Accordingly, in the example presented in FIG. 5, the selected product 106A has predefined styles 1-4 and money managers A-D, identified with reference numerals 110A-110D. These same money managers are identified as money managers 18-24 in FIG. 1A. Similarly, the styles 1-4 are the same styles reflected in the style models, i.e. SM1-SM4, which are combined in the overlay model (OM) applied to the managed client account (MCA) shown in FIG. 1A.
In summary, using the FIG. 1A architecture, the selected risk category determines the asset allocation breakdown, and the available products. Selection of the product determines the styles and money managers for these styles. That is, the styles and money managers for the styles are predetermined for each product, and the allocations and offered products are predetermined for each risk category.
It will be recognized that the required use of predetermined allocations, products, styles and money managers in connection with a selected risk category limits the investor/advisor flexibility. Thus, using the architecture of FIG. 1A, the investor 10 cannot choose desired allocations, or styles, or money managers, but is limited to the predefined allocations, styles and money managers. Accordingly, the most suitable allocations, styles and money managers may not be used to meet the personal needs of the investor 10 using the FIG. 1A architecture.
Client Account Establishment, Security Identifier Tagging, and Tracking
As shown in FIG. 6, using the system architecture of FIG. 1A the brokerage firm 14, in step 120, opens the managed client account MCA for the investor 10, with the overlay manager, represented by the master overlay manager (MOM) 50, and makes a deposit of cash, credit and/or securities into the account in step 122. These deposits could be new assets or assets from a previously opened account of the investor 10 with the brokerage firm 14.
The money managers 18-24 and overlay manager coordinate the combination and incorporation of the style models, i.e. SM1-SM4, shown in FIG. 1A, for the individual styles, i.e. style1-style4, shown in FIG. 5, into the overlay model (OM), shown in FIG. 4. In other words, each individual security is tied to one specific style. Accordingly, the OM can be used to trade securities in all of the individual styles and otherwise manage the MCA.
The MOM 50, in step 136, tags each individual security identifier in the OM with its appropriate style. Preferably, the tagged identifier is the ticker symbol for the security, e.g. IBM, CKFR, KO etc. As shown, security identifier A is tagged with a 1 for style 1 and is represented as SECAID1, security identifier B is tagged with a 2 for style 2 and is represented as SECBID2, security identifier C is tagged with a 3 for style 3 and is represented as SECCID3, and security identifier D is tagged with a 4 for style 4 and is represented as SECDID4. No security identifier may be tagged with two styles.
For example, if security identifier A was included in the OM for both style 1 and style 2, security identifier A could not be properly tagged. That is, security identifier A can only be tagged with a single style. Accordingly, security identifier A can only be included in the OM for one style, e.g. either style 1 or style 2, but not both. Since in this example, security identifier A is included in style 1, a different security identifier must be substituted for security identifier A in style 2. Therefore, in creating the OM in step 138, any duplicate securities within different styles must to be eliminated in step 137. As will be discussed further below, in step 130, the MOM 50 prohibits trading in the same security in different styles. Practically, this also means that each model, i.e. SM1 for style 1, SM2 for style 2, SM3 for style 3, and SM4 for style 4, must include only security identifiers unique to that overlay model and which are not duplicated in any other of the models that may be combined with that model.
The MOM 50 initiates trade orders and otherwise transacts the MCA for the investor 10, in step 124. The BFPMS 32 executes these orders, resulting in the purchase and sale of individual securities 126 and a remaining cash balance 128 in the MCA. The MOM 50 also tracks the performance of the MCA. The MOM 50 tracks the total cash performance for the MCA in step 130. Such tracking may be during its lifetime of the MCA or during a more limited performance period window. The MOM 50 additionally tracks the performance of the securities within the MCA, excluding any cash transactions affecting the performance of that security, in step 132. The MOM 50 combines the cash and security performance numbers in order to compute, and thereby track, the total performance for the MCA, in step 134.
It should be understood that, cash transactions are not tracked on a style-by-style basis, i.e. the cash transactions are only tracked on an entire MCA basis. Thus, the effect of these cash transactions is not reflected in the performance computation for each style. Accordingly, the tracked and reported individual style performance on the account statements generated by the MOM 50 of FIG. 4, may be, and often is, somewhat inaccurate. Therefore, MOM 50 cannot provide the investor 10 with a true style performance, as cash transactions affecting each style are not considered in the performance calculation by the MOM 50.
Additionally, because the OM used by the MOM 50 does not allow duplicate securities across different styles, the MOM 50 restricts the flexibility of each of the money managers 18-24 to select preferred securities for the respective portion of the MCA assigned to its style. Thus, the money managers may be prevented from investing in preferred securities, which could detrimentally affect their performance. Additionally, an individual money manager might even be required to remove certain existing security identifiers from its SM, because the same security identifier exists in another SM. Thus, not only is the MOM 50 unable to accurately assess or report on the performance of the individual money manager styles, the MOM 50 also significantly limits the flexibility of the money managers to control how their respective styles are reflected in the OM. As shown in FIG. 6A, using the system architecture of FIG. 1B the brokerage firm 14, in step 140, opens the managed client account MCA′ for the investor 10, with the overlay manager, represented by the alternate master overlay manager (AMOM) 50′, and makes a deposit of cash, credit and/or securities into the account in step 142. Once again, these deposits could be new assets or assets from a previously opened account of the investor 10 with the brokerage firm 14.
In step 144A-144D, the individual money managers 18-24 open individual managed trading accounts MTA1-MTA4, as shown in FIG. 1B, to be managed in accordance with their individual style models, i.e. SM1-SM4, as also shown in FIG. 1B, for their individual styles, i.e. style1-style4, shown in FIG. 5. A portion of the MCA′ funding is allocated to the MTA1. Although not shown, it will be recognized that allocations are similarly made to MTA2-MTA4.
There is no overlay model (OM). There is also no need for the AMOM 50′ to tag individual securities with the applicable style, since each of the money managers use its style model, i.e. SM1-SM4, to trade and manage the one account, i.e. MTA1-MTA4, in its individual styles. Model SM1 for MTA 1 is identified with reference numeral 148. It should be understood that, although not shown, each of the other MTAs opened in steps 114B-144D would likewise be traded and managed based on an associated one of SM2-SM4.
Since each of MTA1-MTA4 is separately traded and managed, security A can be in both MTA1 and MTA2, and hence traded in accordance with the respective models for multiple styles, e.g. both SM1 or SM2. Therefore, duplicate securities within different styles or SMs need not be eliminated. Practically, this also means that multiple models, i.e. SM1 for style 1, SM2 for style 2, SM3 for style 3, and SM4 for style 4, may hold overlapping securities, i.e. securities which are duplicated in another of the models. The MMPMS 36′ initiates trade orders and otherwise transacts MTA1 in accordance with SM1 for the investor 10, in step 146. The BFPMS 32 executes the trade orders, resulting in the purchase and sale of individual securities 150 and remaining cash balance 152 in MTA1.
More particularly, the money manager 18 tracks the performance of MTA1. The money manager 18 tracks the total cash performance for MTA1 in step 152. Such tracking may be during its lifetime in the MTA or during a more limited performance period window. The money manager 18 also tracks the performance of the securities within MTA1, including any cash transactions affecting the performance of the securities, in step 156. The money manager 18 also tracks the performance of cash and securities within MTA1 individually, as shown in steps 154 and 156 respectively. The money manager 18 combines the cash and security performance numbers in order to compute, and thereby track, the total performance for MTA1, in step 158. The other money managers 120-124 would also transact and track performance of MTA2-MTA4 in a similar manner. In step 160, the respective tracked performances for MTA1-MTA4 are compiled by the AMOM 50′ to track the performance of the MCA′, opened in step 140, as a whole. Alternatively, the performance of the MCA′ as a whole could be computed by the AMOM 50′ using the MCA′ record stored at the AMOM 50′. Because both cash and security transactions are tracked on a style-by-style basis, the effect of the cash transactions is reflected in the style performance computation for each style, as well as in the performance computation for the MCA″ as a whole. Accordingly, both the tracked and reported individual style performance for MTA1-MTA4 generated by the AMMPMS processors 36B′ of each money manager, as shown in FIG. 3, and the total MCA″ performance generated by the AMOM processor 50A based either on the MTA1-MTA4 individual style performances, or the MCA′ record itself, will be accurate. The investor 10 is thus provided with a true style and total account performance, since cash transactions affecting each style are considered in the performance computations by the respective AMMPMSs 36′. Additionally, because the AMOM 50′ does not restrict the inclusion of duplicate securities across different styles, each of the money managers 18-24 is given complete flexibility to manage its respective portion of the MCA′ assigned to its MTA. Thus, none of the money managers 18-24 is forced to alter their preferred style, i.e. their preferred SMs, so as to avoid securities that are already held by or included in the SM of another money manager for a different style.
In summary, the AMOM 50′ is able to accurately assess and report on the individual performance of each of the money managers and MTAs, as well as the combined performance of all the money managers and the total MCA′, without significantly limiting the flexibility of the money managers to manage their respective portions of the MCA′. Since individual securities and cash are tracked in each MTA, accurate performance of each MTA, and the MCA′ as a whole, is available, true account performance statements are generated and reported.
The money managers 18-24 are allowed to hold duplicate securities across multiple styles in the MTAs and independently manage its MTA. Each manager therefore has the flexibility to hold and transact whatever securities it desires for its style. Because each individual MTA serves as its own individual silo, the transactions of one money manager are unknown to the overlay manager and to the other money managers, making it difficult to monitor movements of securities within the entire holdings of the individual investor 10. Therefore, avoidance of a wash sale violation across the multiple MTAs, i.e. performing tax-aware trading that takes into account the multiple MTAs, and rebalancing allocations across MTAs, can be difficult.
On the other hand, the architecture of FIG. 1A incorporates the individual styles into one single MCA, which facilitates the monitoring of movements of securities within the entire holdings of the individual investor 10, and thereby makes wash sale avoidance easy. However, this architecture does not provide the money managers 18-24 full flexibility to invest as desired by prohibiting the same security from being held across different styles, and cannot produce true style performance within the MCA.
Rebalancing Security Drift
FIG. 7 further describes the rebalancing MCA function 50A1 performed by the processor 50A of the MOM 50 shown in FIG. 4, in the architecture of FIG. 1A. It should be understood that the processing described in FIG. 7 is performed within the transact MCA step 124 of FIG. 6. As depicted, the overlay model (OM), stored in the memory 50B of the MOM 50, is compared to the with the managed client account (MCA), stored in the database 50C of the MOM 50, by the processor 50A in step 170. In this regard, the processor 50A, in step 170, compares each individual security allocation in OM to the actual allocation of each security in the MCA, and in step 172 calculates the drift between each of these allocations. Based on the computed drift, the processor 50A determines if rebalancing is required in step 174. If not, no further action is required, as indicated by step 176.
If rebalancing is required and the allocation of a security in the MCA exceeds the weighting of that security in the OM, the processor 50A will determine the amount, e.g. the number of shares, to sell down that security from the MCA in step 178. On the other hand, if the allocation of a security in the MCA is below the weighting of that security in the OM, the processor 50A will determine the amount, e.g. the number of shares, of the security to buy into the MCA in step 178. The execution of the applicable trades for the determined amounts of the security to be sold from or purchased for the MCA will re-balance the MCA, and thus the client account (CA) stored at the BFPMS database 32A of FIG. 2 and the custodial client account (CCA) stored in the database 34A of FIG. 1A, back to the OM.
The processor 50A, in step 180, initiates the trade orders and aggregates the orders into a trade block by implementing the generate trade order function 50A5 shown in FIG. 4. The trade block is forwarded to the brokerage firm 14. In step 182 the trades are executed by the brokerage firm 14.
A number of different events could trigger the rebalancing described in FIG. 7. For example, rebalancing might be required due to a change in the OM. Such a change could create drift in the MCA as compared to the modified OM. The change in the OM could, for example, result from a change in the risk tolerance of the individual investor 10. Alternatively, the OM could be changed at the discretion of the overlay manager represented by the master overlay manager (MOM) 50.
Rebalancing might also be required as a result of a deposit or withdrawal from the MCA. Such deposits and withdrawals may, if desired, automatically trigger a rebalancing of the MCA back to the OM. Rebalancing might additionally be required due to market fluctuations. Such fluctuations could be tracked and, if desired, automatically trigger a rebalancing of the MCA back to the OM. The rebalancing for market fluctuation can also be performed periodically, if so desired.
Tax Efficient Trading
FIG. 8 depicts the processing for handling tax efficient trading for an investor 10, using the architecture of FIG. 1A. As shown, in step 185 the investor 10 request, via the financial advisor 12, a tax efficient withdrawal. Such a request could be to sell the most tax-effective lot(s) of specifically identified securities, or to sell the most tax-advantageous lot(s) without identifying the securities. In step 186, the financial advisor 12 requests that the overlay manager, represented by the master overlay manager (MOM) 50 shown in FIG. 4, which manages the managed client account (MCA) stored in database 50C for the investor 10, proceed with a sale of the best tax lots from a tax efficient perspective. Although not shown in FIG. 8, it will be recognized that this request could be a direct request from the advisor 12 to the MOM 50 or could be a request directed via the brokerage firm 14 of FIG. 1A.
Based on the request from the advisor 12, the processor 50A of MOM 50, in step 187, implements the tax efficient trading function 50A2, as also shown in FIG. 4, on the MCA stored in the database 50C, to identify the best securities to sell from that MCA. Typically specific tax lots of individual securities will be identified by the MOM processor 50A. It should be understood that the identified securities may have been selected from any or all of the styles reflected in the overlay model (OM) stored in the memory 50B of the MOM 50 shown in FIG. 4, for the MCA.
The MOM processor 50A, in step 188 implements the generate trade orders function 50A5, as shown in FIG. 4, to generate the trade order(s) to transact the MCA, as indicated in step 124 of FIG. 6, and initiate the tax efficient trades to satisfy the request from the investor 10. The trade order(s) are communicated from the overlay manager to the brokerage firm 14 for execution in step 189. As shown, this communication is made directly from the overlay manager to the brokerage firm 14. In the FIG. 8 processing, the MOM 50 identifies securities from the entire MCA and uses a tax efficient trading tool function 50A2 to trade the MCA, and hence the CA, in the most tax efficient manner for the client. There is no need for the overlay manager to identify the tax efficient securities for selection by the financial advisor 12. Rather, the overlay manager, operating the MOM 50, has all the necessary information to identify and select the best securities to trade, and generates the corresponding trade orders to transact the MCA and forwards the orders to the brokerage firm 14 for execution. FIG. 8A depicts the processing for handling tax efficient trading for the investor 10, using the architecture of FIG. 1B. It should be recognized that a substantially similar process would be required if the architecture of FIG. 1 is utilized.
As shown, in step 190 the investor 10 requests, via the financial advisor 12, a tax efficient account withdrawal. The financial advisor 12, requests, in step 192, that each of the money managers 18-24 managing the managed trading accounts, i.e. MTA1-MTA4, for the investor 10, determine the best tax lots to sell from a tax efficient perspective. Although not shown in FIG. 8A, is will be recognized that this request could be a direct request from the advisor 12 to the money managers 18-24 or could be a request directed via the brokerage firm 14 and/or overlay manager represented by the alternate master overlay manager (AMOM) 50′ in FIG. 1B.
Each of the money managers 18-24 has an associated AMMPMS 36′, as shown in FIG. 3, with one of MTA1-MTA4 stored in the database 36A. Based on the request from the advisor 12, each of the AMMPMS processors 36B, in steps 194A-194D, implements the tax efficient trading function 36B2, as also shown in FIG. 3, on the MTA stored in the database 36A to determine the best securities to sell from that MTA and identifies these securities for the financial advisor 12. It will be recognized that most typically specific tax lots of individual securities will be identified by the AMMPMS processors 36B.
The money managers 18 and 24, in steps 196A and 196B, then select the securities to be sold from those identified by the respective MMPMSs 36′. It should be understood that although, in the exemplary implementation shown in FIG. 8A, securities have been selected from those identified in two of the MTAs, i.e. MTA 1 and MTA4, in practice securities could be selected from more or less of the MTAs depending on the particular situation.
The applicable processors 36B, in steps 198A and 198B implement the generate trade orders function 36B5, as shown in FIG. 3, to generate the trade order(s) to transact MTA1 and MTA4, as shown in step 146 of FIG. 6A, and initiate the tax efficient trades to satisfy the request from the investor 10. The trade order(s) are communicated from the money manager(s) to the brokerage firm 14 for execution in step 199. This communication may be made directly from the money managers 18 and 24, who are responsible for MTA1 and MTA4, or may be via the overlay manager represented by the AMOM 50′. However, this may not be the most optimal tax sale for the investor 10.
Wash Sale Monitoring
Referring now to FIGS. 1A and 4, the process for monitoring wash sale violations will be described for the architecture of FIG. 1A. As shown in FIG. 1A, the master overlay manager (MOM) 50 manages the single master client account (MCA) stored in the MOM database 50C, and initiates all trading associated with the MCA. The MOM 50 manages the MCA in accordance with the overlay model (OM) stored in the MOM memory 50B. The OM represents a combination of the individual style models, i.e. SM1-SM4, of the money managers 18-24. Thus, the MOM 50 transacts the MCA.
A wash sale violation will only occur if the MOM 50 initiates both a sale and a purchase of the same security in a restricted time period. Such situations are easily monitored by the MOM processor 50A implementing the MCA wash sales function 50A3. For example, the MOM 50, executing function 50A3, will ensure that, after initiating a trade order to sell IBM on December 1 at a loss, no trade order to buy IBM is initiated within a restricted period of say 31 days, e.g. on December 29, thereby avoiding a wash sale violation for the investor 10.
Referring to FIGS. 1A and 4, the FIG. 1A architecture can easily monitor and avoid wash sale violations because all transactions, including all trade orders, are initiated by the single master overlay manager (MOM) 50, and no two styles are allowed to have the same security, e.g. IBM securities are only allowed to be held and transacted in one style, e.g. style 1. Hence, if a loss is harvested by selling IBM securities on December 1, and according to the overlay model OM, IBM securities are to be purchased on December 29 of the same year, the processor 50A of MOM 50 will execute the MCA wash sales function 50A3 to check for a sale of IBM securities within the restricted period before initiating a purchase of IBM securities. Since MOM 50 initiated the sale of IBM securities on December 1, it will not initiate the December 29 purchase of IBM securities, thus avoiding the wash sale violation.
Furthermore, because IBM can only be held and transacted in style 1 based on the tagging in the OM, no wash sale violation is likely pursuant to an IBM purchase required by another style represented in the OM. An exception is if one money manager, e.g., money manager A 18, were to eliminate IBM from the style model being managed, e.g., SM!, and another money manager, e.g., SM2 within a wash sale violation period. Thus, the MOM 50 needs to typically only consider transactions associated with a single style in monitoring potential wash sale violation.
Referring now to FIGS. 1B, and 3, the process for monitoring wash sale violations will be described for the architecture depicted in FIG. 1B. As shown in FIG. 1B, the alternate master overlay manager, i.e. AMOM 50′ overlays multiple independently trading accounts, i.e. MTA1-MTA4, which are separately managed by money managers 18-24. Each of the money managers 18-24 self directs and transacts its individual MTA utilizing the MMPMS 36′ shown in FIG. 3. As a result, a sale by one money manager for one of the MTAs and a purchase by another money manager for another of the MTAs may result in a wash sale violation.
Such situations are difficult to monitor. For example, if money manager 18 initiates a trade order to sell IBM from MTA1 on December 1 at a loss, and money manager 24 initiates a trade order to buy IBM for MTA4 within, for example, 31 days, i.e. on December 29, a wash sale violation for the investor 10 would result. Since the money managers 18-24 initiate all transactions independently, and the MCA′ stored in the AMOM database 50C is merely a compilation of MTA1-MTA4, the AMOM 50′ is incapable of monitoring these transactions, except to the extent that the individual money managers either promptly report the transactions to the AMOM 50′ or are required to forward all initiated trade orders to the brokerage firm 14 via the AMOM 50′.
Rebalancing Cross Style Drift
Referring now to FIGS. 1A, 4, 6 and 7, the process for monitoring drift will be described for the architecture of FIG. 1A. As depicted in FIG. 1A, master overlay manager, i.e. MOM 50 shown in FIG. 4, manages the single master client account (MCA) stored in the MOM database 50C, and initiates all trading associated with the MCA. The MOM 50 manages the MCA in accordance with the overlay model (OM) stored in the MOM memory 50B, which represents a combination of the individual style models, i.e. SM1-SM4, of the money managers 18-24.
As a result, as described with reference to FIG. 6, MOM processor 50A implements the MCA cross style drift function 50A4 by first monitoring drift over the entire account. That is, the MOM processor 50A computes the security drift in step 172 of FIG. 7, on a security-by-security basis by comparing each of the securities in the MCA to the target for that security in the OM.
The processor 50A then implements the rebalance MCA function 50A1 to perform to perform steps 174 and 178 of FIG. 7, and thereby rebalance the MCA by reducing or eliminating the computed security drift.
However, the MOM 50 is incapable of accurately monitoring cross style allocation drift of the MCA from the cross style allocation set forth in the OM, or of rebalancing across styles, since it does not contain style-specific cash buckets and thus cannot calculate accurate asset valuations for each style. Rather, the MOM 50 only monitors and rebalances on a security-by-security basis within the MCA with respect to the individual security targets in the OM.
Referring now to FIGS. 1B and 3, the process for monitoring drift will be described for the architecture of FIG. 1B. As depicted in FIG. 1B, each of the individual money managers, represented by MMPMS 36′ shown in FIG. 3, independently manages the single managed trading account (MTA1-MTA4 stored in the MMPMS database 36A, and initiates all trading associated with the applicable MTA. Each MMPMS 36′ manages its MTA in accordance with the style model, i.e. SM1-SM4, of the applicable one of the money managers 18-24, stored in the MMPMS memory 36C.
As a result, the processor 36B of each MMPMS 36′ implements the drift function 36B4 to monitor drift over the applicable MTA. That is, the MMPMS processor 36B computes the drift, on a security-by-security basis by comparing each of the securities in the applicable MTA to the target for that security in the applicable SM. The processor 36B then implements the rebalance MTA function 36B1 to rebalance the MTA by reducing or eliminating the computed security drift. Since each of the styles is managed independently by a separate money manager, and in accordance with a different SM, the MMPMS 36′ is incapable of monitoring drift across styles, i.e. drift across MTA1-MTA4, or rebalancing across style drift. Rather, the AMOM 50′ could potentially monitor across style performance or value differences for MCA′ using the information provided by the separate MMPMS 36′ reports for MTA1-MTA4. However, AMOM 50′ does not currently include such functionality. If it did, the AMOM 50′ has no overlay model or management functions, and therefore still could not determine drift or initiate trades to rebalance across styles within the MCA′.
Thus, in the FIG. 1B architecture, drift is monitored only within separately managed accounts. Each money manager, using its MMPMS 36′ can produce drift reports for the MTA it manages for the investor 10. For example, money manager 18, using its MMPMS 36′, would determine drift for MTA1 and rebalance MTA1 to SM1 if necessary, and money manager 20, using its MMPMS 36′, would determine the drift for MTA2 and rebalance MTA2 to SM2. To rebalance an individual MTA, the trade orders generated by the applicable MMPMS 36′ are separately forwarded to and executed by the brokerage firm 14. There would be no movement of assets between MTA1-MTA4. Any asset allocation rebalancing across MTAs must be performed manually.
Therefore, if the value of MTA1, managed by money manager 18, has increased to a value exceeding the originally allocated value of MTA1, the additional value would remain in MTA1, and none of the assets of MTA1 would be moved to MTA2-MTA4.
Cash Deposit Allocations
As discussed above with reference to FIGS. 5 and 6, in the FIG. 1A architecture, a cash deposit of $10,000 made by the investor, 10 is allocated to a single overlay manager, represented by the master overlay manager (MOM) 50, and hence, to the single managed client account (MCA). The MOM 50 enters the $10,000 into the MCA, shown in FIG. 4.
The overlay model (OM), shown in FIG. 4, does not perform any further allocations of the $10,000 cash deposit. Rather, the MOM 50 uses the cash deposit to transact the MCA in accordance with the OM, e.g. to purchase securities in the various styles, i.e. style1-style4, for the MCA. The individual money managers 18-24, whose style models SM1-SM4 form the OM, do not participate in the transacting of the MCA or the allocation of the $10,000 deposit.
Furthermore, there is no discretion for the MOM 50 to make cash allocations of portions of the $10,000 cash deposit to each of the styles reflected in the OM or to the money managers 18-24 to trade individually. Rather, the cash is entered and retained in the MCA by the MOM 50 as a single cash pool, and is not associated with any particular style. The MOM 50 then draws from this single cash pool as required to transact style1-style4 in accordance with the OM.
As discussed above with reference to FIG. 6A, in the FIG. 1B architecture, cash deposits are allocated amongst the multiple managed trading accounts, i.e. MTA1-MTA4. For example, a $10,000 deposit made by the investor 10 could, for example, be divided such that $3,000 is allocated to MTA1 and managed by money manager 18, $2,000 is allocated to MTA2 and managed by money manager 20, $4,000 is allocated to MTA3 and managed by money manager 22, and $1,000 is allocated to MTA4 and managed by money manager 24. Each of the managers 18-24 enters the applicable cash allocation as a deposit into its associated MTA for the investor 10 and uses the allocated cash to transact the MTA, e.g. to purchase securities for the MTA.
Maintaining Cash Balances
In the architecture of FIG. 1A the overlay manager, which as shown in FIG. 4 is represented by the master overlay manager (MOM) 50, manages a single managed client account (MCA) in accordance with a single overlay model (OM). Therefore, as shown in FIG. 6, cash is maintained as a single pool of cash, or within what can be characterized as a single cash bucket. Securities are likewise maintained as a single pool of securities, or within what can be characterized as a single securities bucket, even though there are multiple styles reflected in the OM.
Hence, in the FIG. 1A architecture, each individual style, e.g. style1-style4, does not have its own individual cash balance. Instead, the incorporation of the multiple styles into a single MCA for the investor 10 results in the MOM 50 being able to generate only a single cash balance for the entire MCA. Thus, the MOM 50 is incapable of maintaining a division of cash among the different styles reflected within the OM. On the other hand, in the architecture of FIG. 1B cash balances, as well as securities, are maintained within each of the managed trading accounts, i.e. MTA1-MTA4, by the money managers 18-24. Therefore, as discussed above with reference to FIG. 6A, there are for cash balances, one associated with each of MTA1-MTA4, for the single client managed account (MCA′) at the AMOM 50′ shown in FIG. 4.
Rebalancing Style Allocations in Multiple Managed Client Accounts (MCAs)
As discussed above with reference to FIGS. 4 and 5, using the FIG. 1A architecture, the initial allocations are set based on the selected product 106A-H. Although the initially established allocations may change from time-to-time, the current allocations are applied to the managed client accounts (MCAs) for all investors which are managed in accordance with the applicable overlay model (OM). Thus, the MCAs are always rebalanced back to that current allocation in accordance with the applicable OM. FIG. 11 depicts OM 220, which could serve as the OM shown in FIG. 4, having an allocation 224 across the styles 222. The styles 222 correspond to style1-style4 depicted in FIG. 5. An exemplary computation of security drift and determination as to whether or not rebalancing is required, as performed in steps 172 and 174 of FIG. 7, will be described below with reference to FIG. 11.
As shown, the OM 220 has an allocation 224 of 40% value, 30% growth, 20% small cap, and 10% large cap.
The master overlay manager (MOM) 50, as shown in FIG. 4, opens MCAs to be managed under the OM at the designated allocations. Hence, the MCA1 for investor 10, identified with reference numeral 226, is opened on a particular date with the styles 222 and an actual allocation 228 of 40% value, 30% growth, 20% small cap, and 10% large cap. As time elapses, the allocations between these four styles in the MCA1 for investor 10 will fluctuate as indicated by block 230. The values of the securities within the individual styles will move in line of stock market or other fluctuations. We will assume, for purposes of this example, that after 30 days the actual allocations 228A of styles 222 in the MCA1 226 for investor 10 fluctuate to 45% value, 28% growth, 17% small cap and 10% large cap.
MCA2 232 for another investor, i.e. an investor other than investor 10, is opened on the 30th day after the opening of MCA1 226, with an actual allocation 234 for the styles 222 of 40% value, 30% growth, 20% small cap, and 10% large cap, which of course is identical to the OM allocation. As time elapses, the allocations between these four styles in MCA2 for this other investor will also fluctuate, in line of stock market and/or other fluctuations.
Therefore, although MCA1 226 and MCA2 232 are subject to management by the MOM 50 using the same OM 220, MCA1 226 will have a different actual allocation than MCA2 232 on the 30th day after opening MCA1 226. That is, 30 days after the opening of MCA1 226 for investor 10, MCA1 will have actual allocations 228A of 45% value, 28% growth, 17% small cap and 10% large cap while the MCA2 232 for the other investor will have actual allocations 234 of 40% value, 30% growth, 20% small cap, and 10% large cap, even though both of these MCAs are managed in accordance with the same OM 220. As noted above, differences in allocations between MCAs for different investors may also occur at any particular time because of varying account activities, such as different deposits being made by different investors during the lives of the MCAs.
Hence, the MOM 50 determines, in 236, that the actual allocation 228A for MCA1 226 must be rebalanced in 236, back into line with the OM allocation 224, and performs the rebalancing i.e. from 45% value, 28% growth, 17% small cap and 10% large cap to 40% value, 30% growth, 20% small cap, and 10% large cap, in block 240. It also determines, in 238, that no rebalancing of the actual allocation 234 for MCA2 232 is required and hence does nothing with the MCA2 232 current actual allocation 234 as indicated by block 242.
Similarly, MCAs associated with other investors (not shown) may not require any rebalancing or may require a different rebalancing from that of MCA1 226. As indicated above, the different rebalancing may be required either because such other MCA was opened at a different time than MCA1 226, or was subject to account activity different than that to which the MCA1 226 was subjected.
Thus, on the 30th day after the opening date of MCA1 226, multiple MCAs managed under the same OM 220 will often need to be rebalanced from different current actual allocations back to the OM allocation 224, i.e. back to 40% value, 30% growth, 20% small cap, and 10% large cap. This will in turn require a substantial number of different trades, and accordingly substantial processing by the MOM 50, to bring the allocations of each of the MCAs for the different investors which are managed according to the same OM, e.g. OM 220, back into line with the allocation 224 set forth in the OM. In summary, a single OM is typically used for multiple MCAs of different investors, which can number in the thousands or even tens of thousands. Each of these MCAs may be subject to a different allocation drift during regular reporting periods, such as the 30 day period referenced above, due to varying opening dates or account activity. Accordingly, many of the MCAs will often need to be separately rebalanced back to the OM allocation every reporting period. This results in a significant amount of processing by the MOM to determine if each MCA needs rebalancing and to initiate different trades to rebalance different MCAs. Furthermore, this will also result in a significant amount of trading by the brokerage firm 14 being required. The trading may in turn result in additional tax issues for the investors.
It should also be recognized that, in the architecture shown in FIG. 1A, because of a need to maintain the OM allocation across the multiple styles for many MCAs, the MOM 50 rebalances allocations, without consideration of factors which may be relevant to an individual investor. For example, it may be beneficial for the allocation to follow a particular investment trend over a period of market activity or for the allocation to be varied from the current OM allocation to avoid a high number of trades or tax consequences that might otherwise result in bringing the current actual allocation in line with the original OM allocation. However, this is not possible in the FIG. 1A architecture because the style allocation in the OM are fixed and the number of OMs are finite.
The Overlay Model and Managed Client Account
FIG. 9 further details an exemplary overlay model 200, suitable for use in the FIG. 1A architecture. As discussed above with reference to FIG. 6, the overlay model is created with the security identifiers tagged with a single style indicator. This tagging allows the master overlay manager (MOM) 50 to track the securities that are purchased for or sold from the managed client account (MCA) on a style-by-style basis for the multiple styles, i.e. style1-style4.
As shown, the overlay model 200, and discussed with reference to FIG. 6, combines multiple style models, i.e. SM1-SM4, for multiple investment style1-style4. Within each of the SM's incorporated in the OM is a list of security identifiers, e.g. IBM, CKFR, KO, PFE, C, F, T, and GM etc., along with a percentage weight, e.g. 5%, 4%, 8%, 1%, 2% and 3% etc., for each of the identified securities. The identifier for each security is preferably the symbol utilized by the stock exchange on which that security is traded. However, this is not mandatory. Each security identifier is tagged, or otherwise associated with, the specific style of the model from which it originated, and thus to a specific one of styles 1-4 being utilized by the overlay manager to manage the MCA for investor 10. As shown, IBM and CKFR are tagged with the superscript 1 and thereby associated with style 1, KO and PFE are tagged with the superscript 2 and thereby associated with style 2, C and F are tagged with the superscript 3 and thereby associated with style 3, and T and GM are tagged with the superscript 4 and thereby associated with style 4.
In the FIG. 1A architecture, an identified security can only exist in one individual style model. Duplicate securities across different style models are not allowed in the overlay model 200. As a result, when the MCA is transacted in step 124 of FIG. 6, the tax lots of each security purchased for or sold from the MCA can be associated with the appropriate style since the security identifier for the securities is associated with only one style reflected in the OM. Thus, a purchase of IBM securities for the MCA will necessarily be associated with style 1 by the MOM 50, because the IBM security identifier in the OM is tagged to style 1. On the other hand, a sale of GM securities from the MCA will necessarily be associated with style 4 by the MOM 50, because the GM security identifier in the OM is tagged to style 4. Thus, each tax lot of securities can be associated by the MOM 50 to an individual investment style reflected in the OM, because the OM prohibits the purchase or sale of such securities for any style except the style to which the identifier for those securities has been tagged. Therefore, all transactions relating to a particular identified security, such as IBM, will be tracked by the MOM 50 in the style with which the identifier of the security is tagged in the OM. The MOM 50 will prohibit any style incorporated in the OM, other than SM1, from including the IBM identifier, thereby prohibiting transactions in IBM securities in other styles.
FIG. 9A further details an exemplary managed client account (MCA) 202, suitable for use in the FIG. 1A architecture. As discussed above with reference to FIG. 6, the MCA 202 includes the information necessary to track security performance on a style-by-style and total client account basis.
As shown, the MCA 202 includes a listing of the securities within the MCA. As indicated, the MCA includes 100 shares of IBM, purchased as tax lot KTFC on Jan. 3, 1985, and 50 shares of CKFR, purchased as tax lot CHFP on Jan. 5, 2003, etc. The MCA also includes a cash listing showing $10,000. Using the tagged identifiers in the OM, the MOM processor 50A, of FIG. 4, can retrieve the information from the MCA and associate each of the securities represented in the MCA with a particular style. This information is processed by the MOM processor 50A by executing the generate MCA statement function 50A6, to compute the performance results for the MCA, and hence CA, as a whole, as well as the performance results for the securities in the individual styles. As noted above, the individual style performances results will be somewhat inaccurate due the lack of consideration of the cash transactions on a style-by-style basis.
Tracking Security Movement and Account Performance
FIG. 10 depicts the process performed to initiate trades in the FIG. 1A architecture. In step 204, the investor 10 requests a purchase or sale of securities, typically via the financial advisor 12. In the example shown, the financial advisor 12 forwards a request to sell 50 shares of IBM and 20 shares of KO from the managed client account (MCA) 202, from the 100 shares of IBM and 50 shares of KO in the MCA, as shown in FIG. 9A and recorded in the database 50C of the master overlay manager (MOM) 50 depicted in FIG. 4. The selection of the IBM and KO could have been included in the investor's request if so desired.
In accordance with the OM 200 used for the MCA 202 of investor 10, IBM securities can only be held and transacted in style 1 and KO securities can only be held and transacted in style 2. Hence, any purchase or sale request must necessarily be limited, in the case of IBM to style 1, and in the case of KO to style 4, because these securities can only be held and transacted in those styles. The MOM processor 50A can thereby track the sale of the IBM securities as a sale from the portion of the MCA 202 managed under style 1 and the sale of the KO securities as a sale from the portion of the MCA 202 managed under style 2. The MOM processor 50A, in step 210, implements the generate trade order function 50A5 to initiate trade orders to sell the 50 shares of IBM securities and the 20 shares of KO securities from the MCA 202 of FIG. 9A. The brokerage firm 14, in step 212, executes the trade orders.
As described with reference to FIGS. 9, 9A and 10, in the architecture of FIG. 1A the overlay manager, represented by the master overlay manager (MOM) 50 shown in FIG. 4, generates reports on the performance of both the individual styles reflected in the overlay model (OM) as well as on the entire managed client account (MCA). However, as discussed with reference to FIGS. 9, 9A and 10, security identifiers, such as IBM, are tagged with the style in which they are to be transacted. The securities are then purchased and sold based on trade orders initiated by the MOM 50 in accordance with the OM. However, such purchases and sales are not tracked on a style-by-style basis.
Because each security identifier, e.g. IBM, KO etc., within each style in the OM is tagged to its applicable style and the MOM 50 prohibits a security identifier from being tagged to more than one style, the performance of securities currently in an MCA can be tracked on a style-by-style basis. However, the tracked performance for each individual style will not be accurate.
For example, as shown in FIG. 12, money manager A, identified in FIGS. 1A and 12 with reference numeral 18, who is responsible for the style model for style1, i.e. SM1, which is incorporated in the OM 200 shown in FIG. 9, requests, in step 250, that the master overlay manager (MOM) 50 remove IBM from style1 of the OM 200. Money manager D, identified in FIGS. 1A and 12 with reference numeral 24, who is responsible for the style model for style4, i.e. SM4, which is also incorporated in the OM 200, requests, in step 252, that the MOM 50 add IBM to style4 of the OM. The MOM 50, in step 254, retags the IBM identifier in the OM 200 from IBM1 to from IBM4 in accordance with the requests from money managers 18 and 24.
Practically, this results in IBM securities residing in the managed client account (MCA) shown in FIG. 9A, being removed from style1 and being added to style4. Furthermore, it is unnecessary to trade the IBM securities from the MCA. Rather, the existing IBM securities which were previously associated with style1 in the OM 200 remain in the MCA, but are now associated with style4 in the OM 200. However, because there is no movement of or change to the IBM securities in the MCA, there is also no way for the MOM 50 to track the performance ramifications of the removal of the IBM securities from style1 of the OM 200 and addition of these securities to style4 of the OM 200. Therefore, the computed performance of the MCA for both style1 and style4 will necessarily be skewed because there internal transaction of the IBM securities is not tracked.
It should also be recognized that, since the MOM 50 maintains a single cash bucket, as discussed above, it is also incapable of tracking cash movements for the MCA on a style-by-style basis. Without the ability to track cash deposits and withdrawal on a style-by-style basis, the MOM 50 cannot compute the actual cash performance on a style-by-style basis.
Hence, for both the above reasons, the MOM 50 is incapable of accurately calculating and reporting performance of the OM 200 on a style-by-style basis. The MOM 50 can, however, accurately compute and report on the total MCA performance. Thus, in moving from the multiple trading account architecture to that of FIG. 1B, the ability to track individual style performance has been lost.
In the architecture depicted in FIG. 1B, both the tracking of the movement of securities within a particular MTA and the computation of the performance of that MTA is performed by the money manager 18-24 responsible for that MTA. The respective performances of MTA1-MTA4 may be compiled in a single managed client account (MCA′) performance by the overlay manager represented using the AMOM 50′, as shown in FIG. 4.
Because each of the MTAs is separately managed, the applicable money manager completely controls the single style model (SM) according to which the MTA is managed and the transacting of the MTA. Therefore, each money manager can easily track the movements of securities and cash into and out of the MTA it manages for the investor and the performance of that MTA. The performance of the MTA is typically tracked to a finite or granular level sufficient to provide a true performance of the MTA. Since each MTA represents one style, the performance of each style is accurately tracked.
For example, if MTA1, as shown in FIG. 1B is a growth account, MTA2 is a value account, MTA3 is a fixed income account, and MTA4 is a small cap account, movements of securities and cash into and out of each of MTA1-MTA4 are separately tracked. Because both cash and securities movements are accurately tracked, the total account performance of any of the MTAs can also be accurately tracked. With respect to securities, it will be recognized by those skilled in the art that the movement of securities into and out of a particular MTA will contribute to the MTA performance. Therefore, as securities are bought for and sold from an MTA, the dates and price at which these securities are bought and sold is tracked.
Movements of a security from one MTA to another, and therefore from one style to another, can be tracked in two different ways using the FIG. 1B architecture. A first way is to sell the security, e.g. IBM out of one account, e.g. MTA1, and buy the same security into another account, e.g. MTA2. In so doing, IBM securities will be moved out of the one style and into another style. However, selling the same security from MTA1 and buying it into MTA2 for the same investor 10 results in potential problems and inefficiencies.
One such problem is that investor 10 may suffer negative tax consequences due to the buying and selling of the same security. For example, there is a potential for a wash sale violation, as has been discussed above. Additionally, selling IBM for a short term gain from MTA1, as desired by money manager 1B, may be less beneficial to the investor than retaining IBM in MTA1 and subsequently selling it for a long term gain, in view of the desire of money manager 20 to buy IBM into MTA2. Another problem is that the sale from MTA1 and purchase into MTA2 of IBM will result in trading for the brokerage firm 14, and additional work for money manager 18 who manages MTA1 and money manager 20 who manages MTA2.
A second way to move securities between styles is to simply deliver securities, e.g. IBM securities, from one managed trading account, e.g. MTA1, into another managed trading account, MTA2, without actually trading the securities. However this requires coordination between two different money managers, e.g. money manager 18 for MTA1 and money manager 20 for MTA2. This would have also required coordination with the brokerage firm 14 to coordinate the movement from one custodial trading account, e.g. CTA1, to another custodial trading account, e.g. CTA2, as shown in FIG. 1.
Thus, delivery of securities from one MTA to another MTA is possible using the FIG. 1B architecture, including movements of securities between MTAs if a particular type of security is to be eliminated from one MTA style model, e.g. from MTA1, and added to another MTA, e.g. MTA2. However, to do so requires coordination between the money managers for the applicable MTAs and the overlay manager represented by AMOM 50′.
In summary, using the architecture of FIG. 1B, cash and security deposits and transactions for each MTA, as well as the individual performance of each MTA, can be accurately tracked and reported by the applicable MMPMS 36′ shown in FIG. 3. The individual MTA performances can be compiled by the AMOM 50′ of FIG. 4 to provide an accurate total client account performance. Thus, individual style performance as well total investor account performance can be accurately tracked and reported to the investor 10 using the FIG. 1B architecture.
Netting Security Transactions
In the FIG. 1A architecture, the master overlay manager (MOM) 50 of FIG. 4 is incapable of netting different transactions in a particular type of security, such as IBM, except in the case where the security is to be completely eliminated from one style type and added to another of the style types at the same time.
As discussed above with reference to FIG. 6, a security identifier, e.g. in this case we will use IBM, is initially tagged with a style1 indicator. Accordingly, IBM securities may only be included in style1 of overlay model (OM), such as OM 200 shown in FIG. 9. As described with reference to FIG. 12, the MOM 50 may, if desired, retag the IBM identifier in the OM 200 with a style4 indicator, if IBM is to be removed from style1 and added to style 4 in OM 200. By performing this retagging, the 100 shares of IBM represented in the MCA 202 of FIG. 9A will tracked as part of the style4 securities portfolio, rather than the style1 securities portfolio of investor 10. It will be noted that no change has been made to the MCA shown in FIG. 9A.
Since the MOM 50 prohibits IBM from being tagged with more than one style at any given time, if only 50 shares of IBM securities are to be removed from the style1 portfolio represented in the MCA 202, these shares could not be transferred to the style4 portfolio represented in the MCA 202. That is, in order to transfer only 50 of the 100 shares of IBM in the MCA to style4, the IBM identifier would need to be tagged with both style1 and style 4 in the OM 200, and this is prohibited. The MOM 50 cannot track IBM securities in multiple styles. Therefore, only if the 100 shares of IBM securities are completely from the style1 portfolio in the MCA thereby allowing the style1 tag removed from the IBM identifier in the OM, can the IBM identifier be retagged with another style identifier, such as the style4 tag, and some or all of these shares of IBM securities in the MCA be moved to the style4 portfolio in the MCA.
Thus, the architecture of FIG. 1A also does not accommodate a netting of trades in a single security type, such as in shares of IBM securities, since trades in the same type of security, e.g. IBM securities, under different styles are not allowed. The architecture therefore limits the flexibility of the money managers 20-24 for styles 2, 3, and 4 to include IBM securities in the style models SM2-SM4 that are incorporated into the OM or to buy IBM securities until IBM is removed from style 1 in the OM.
Using the architecture of FIG. 1B and as discussed above with reference to FIG. 6A, the individual money managers 18-24 initiate transactions and exclusively manage the respective MTAs. Thus, two different money managers may initiate different trade orders to transact the same type of security, e.g. in this case IBM, for different MTAs at any time.
For example, money manager 18, via its MMPMS 36′, could initiate a trade order to sell 50 shares of IBM securities from MTA1 of investor 10, while at substantially the same time, money manager 24, via its MMPMS 36′, could initiate a trade order to buy 100 shares of IBM securities for MTA4 of investor 10. Trading in the same type security, i.e. IBM in this example, for the same investor managed client account (MCA′) on the same day will necessarily result in inefficiencies. However, in the architecture of FIG. 1B, such inefficiencies are very difficult to avoid, since money manager 18 independently initiates the sale of the 50 shares of IBM securities and money manager 24 independently initiates the purchase of the 100 shares of IBM securities.
These two separate transactions could potentially be netted to a single transaction, since a net buy of 50 shares of IBM securities for MTA4 is all that is required to fulfill both the desired sale by money manager 18 and the desired purchase by money manager 24. However, this requires that the 50 shares of IBM securities in MTA1 be moved from MTA1 to MTA4. Since money managers 18 and 24 transact MTA1 and MTA4 independent of each other, and communications between the money managers 18-24 rarely, if ever, occur, such movements of securities between MTAs has proven to be impractical.
Thus, using the architecture of FIG. 1B, transactions in the same security type, such as in IBM, initiated by different money managers are typically not netted, and therefore may be performed inefficiently using multiple trades when only one trade is actually necessary. The multiple trades may in turn subject the investor 10 to undesirable tax consequences and additional brokerage firm costs. However, this has been accepted as a cost of providing individual money managers with control over the management and transacting of accounts pursuant to their respective style models.
Account Management Flexibility
Using the architecture of FIG. 1A a single client account (CA) and corresponding managed client account (MCA) exists. The MCA is transacted and otherwise managed exclusively by the overlay manager represented by the master overlay manager (MOM) 50, in accordance with the overlay model (OM) which is a combination of the style models (SM1-SM4) of the multiple money managers 18-24.
The individual money managers 18-24 are prohibited from trading or otherwise transacting or managing the MCA. Hence, the only involvement of each of the money managers 18-24 is in providing its SM for incorporation into the OM. The MOM 50 initiates all the trading and other transactions, and performs all reporting on the MCA. The money managers 18-24 can, and do from time to time, make changes to SM1-SM4 and forward these changes to the overlay manager. However, although these changes may reflect a desire of a money manager that the MCA be transacted, the money managers cannot initiate the desired transactions, and must instead rely on the discretion of the overlay manager, represented by the MOM 50, to perform in a timely manner the desired transactions. In practice, a money manager is not advised as to when, or even if, such desired transactions are initiated. Yet, the money manager remains subject to being judged on the performance of the relevant portion of the MCA. Accordingly, the architecture of FIG. 1A, with its single MCA for the investor 10, substantially reduces the management flexibility of the individual money managers, limits the ability of the individual managers to report on, or even track, style performance, and eliminates the ability of individual money managers to trade within the portion of the MCA subject to its style model. Thus, the control over the management and transacting of the MCA is effectively removed from the money managers and given to the overlay manager.
Using the architecture of FIG. 1B, the individual managers 18-24 have total control over the management and transacting of the individual managed trading accounts, i.e. MTA1-MTA4, of the investor 10. Each money manager has complete flexibility in trading its individual MTA.
For instance, money manager 18 has exclusive control over the transacting of MTA1 for investor 10. Thus, money manager 18 can, if desired, add 2% of IBM securities to MTA1 by simply modifying SM1 and initiating, via its MMPMS 36′ as shown in FIG. 3, a purchase of the addition 2% of IBM securities. Money manager 18 could also independently adjust MTA1 by selling and/or buying individual securities which are not mandated by SM1. Money manager 18 can perform tax efficient trades using the MMPMS 36′, as previously discussed, although the tax effectiveness would not consider other managed trading accounts, i.e. MTA2-MTA4, of the investor 10. Thus, money manager 18 manages MTA1 independently from the other money managers 20-24, and has full discretion over MTA1.
Additionally, money manager 18, using its MMPMS 36′, can generate all MTA1 specific reports, and can accurately track the performance of MTA1 and movements of the specific holdings within MTA1. Because money manager 18 has complete and accurate information regarding MTA1, it can also accurately perform all desired analysis relating to MTA1.
Accordingly, the architecture of FIG. 1B, with its multiple MTAs for the investor 10, provides complete management flexibility to the individual money managers, provides the individual managers with the ability to accurately report on and accurately track style performance, and provides the individual money managers with the ability to trade within a MTA. Thus, the control over the individual MTAs effectively remains with the money managers and is not given to the overlay manager. However, since control is decentralized, the FIG. 1B architecture lacks various benefits provided by the centralized control in the FIG. 1A architecture, specifically: a single custodial account, across-style rebalancing, a single point of trading control, tax-efficient trading across styles, and the ability to identify and prevent wash sale violations.